3장. 평가 방법론

출처 — Chip Huyen, 『AI 엔지니어링』(한국어판), 3장 (pp. 153~199). 원문 PDF ai_engineering_final_v11_260909.pdf (2026-09-09 판)

파운데이션 모델은 개방형이라 정답이 하나가 아니다 — 그래서 "평가"라는 말 자체가 여러 가지를 가리킨다. 이 장은 언어 모델의 내부 성능을 재는 지표(엔트로피·교차 엔트로피·퍼플렉시티)부터, 응답이 정확한지를 확정적으로 판정하는 방법(기능적 정확성·유사도 측정), 그리고 AI가 AI를 채점하게 하는 방법(AI 평가자·비교 평가)까지 — 파운데이션 모델을 잴 때 쓰는 도구 상자를 통째로 연다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 파운데이션 모델이 전통적인 ML 모델보다 평가하기 어려운 이유 네 가지를 설명한다.
• 엔트로피·교차 엔트로피·퍼플렉시티의 관계를 수식으로 설명하고, 퍼플렉시티 값을 해석하는 세 가지 규칙(구조화 정도·어휘 크기·컨텍스트 길이)을 적용한다.
• 기능적 정확성과 참조 데이터 유사도 측정(정확한 일치·어휘적 유사도·의미적 유사도)의 차이를 구분하고, 각각이 적합한 작업 유형을 판단한다.
• AI 평가자용 프롬프트를 구성 요소별로 설계하고, 그 한계(비일관성·기준 모호성·비용·편향)를 설명한다.
• 개별 평가와 비교 평가의 차이를 설명하고, 비교 평가가 안고 있는 확장성·표준화 문제와 그 완화책을 비교한다.

전체 흐름도

[ 왜 파운데이션 모델 평가가 어려운가 (§1) ]
   개방형 응답 · 정답 목록 불가능 · 블랙박스 · 범용 모델은 평가 범위까지 늘어남
        │
        ▼
[ 언어 모델링 지표 — 모델 내부 성능 (§2~§3) ]
   엔트로피 H(P) → 교차 엔트로피 H(P,Q) → BPC/BPB → 퍼플렉시티 PPL
   해석 규칙: 구조화된 데이터일수록↓ · 어휘 크기 클수록↑ · 컨텍스트 길수록↓
        │
        ▼
[ 개방형 응답의 "정확한" 평가 (§4~§6) ]
   ├─ 기능적 정확성(§4) — 실행해서 "된다/안 된다"로 확정 (pass@k)
   └─ 참조 데이터 유사도(§5~§6)
        ├─ 정확한 일치 · 어휘적 유사도(편집 거리 · n-gram · BLEU/ROUGE)
        └─ 의미적 유사도 → 임베딩(§6) → 코사인 유사도
        │
        ▼
[ 개방형 응답의 "주관적" 평가 — AI 평가자 (§7) ]
   프롬프트(작업 + 기준 + 점수 체계) → AI 평가자 → 점수 + 근거
   장점: 빠름 · 저렴 · 참조 불필요        한계: 비일관성 · 기준 모호 · 비용 · 편향(자기 · 위치 · 장황성)
        │
        ▼
[ 모델 순위 정하기 — 비교 평가 (§8) ]
   개별 평가(점수 매기기) vs 비교 평가(둘 중 승자 고르기) → Elo/Bradley-Terry → 순위
   과제: 확장성 병목(모델 쌍 수 ∝ N²) · 표준화 부재 · "비교 성능"이 "절대 성능"을 보장하지 않음
        │
        ▼
   4장(AI 시스템 평가하기) — 이 장의 지표들로 실제 평가 파이프라인을 설계한다

0. 용어 사전

참고 — 위쪽 5개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 1장·2장을 먼저 보면 좋다. 판정 기준 — 「이 말을 모르면 이 장을 못 읽는가」. 이 장에서 처음 설명하는 개념(엔트로피·퍼플렉시티·AI 평가자 등)은 선행이 아니다 — 본문의 몫이므로 아래 표에 없다.

1. 파운데이션 모델 평가가 어려운 이유

ML 모델 평가는 원래부터 어려웠지만, 파운데이션 모델은 그 어려움을 한층 더 키운다. 네 가지 이유가 있다.

첫째, 모델이 똑똑해질수록 오히려 평가가 더 어려워진다. 초등학교 1학년 수준의 산수 풀이가 틀렸는지는 누구나 알 수 있지만, 박사 수준의 수학 풀이가 맞는지 판정할 수 있는 사람은 거의 없다. 책을 요약한 결과가 터무니없으면 바로 알 수 있지만, 그럴듯하게 읽히는 요약은 진짜 정확한지 확인하려면 책 전체를 다시 읽어야 할 수도 있다. 즉 작업이 정교해질수록 "그럴듯해 보인다"만으로는 평가할 수 없고, 사실 확인·추론·전문 지식이 함께 필요해져 평가 자체에 드는 시간이 늘어난다.

둘째, 개방형 특성 때문에 "정답과 비교하기"가 통하지 않는다. 전통적인 ML은 분류처럼 답이 정해진 폐쇄형 작업이 많아, 실제 출력을 미리 정해 둔 정답과 비교하면 그만이었다. 그러나 개방형 작업에는 하나의 입력에 여러 개의 정답이 있을 수 있고, 있을 수 있는 정답을 모두 나열한 목록을 완벽하게 만드는 것은 애초에 불가능하다.

셋째, 대부분의 파운데이션 모델이 블랙박스다. 모델 제공업체가 아키텍처·학습 데이터·학습 과정을 공개하지 않거나, 개발자가 이를 이해할 전문 지식이 부족한 경우가 많다. 모델 내부를 알 수 있다면 강점·약점을 짚어 더 정밀하게 평가할 수 있지만, 그렇지 못하면 출력 결과만 보고 판단할 수밖에 없다.

넷째, 범용 모델은 평가해야 할 범위 자체가 넓어졌다. 작업 특화 모델은 학습받은 작업의 성능만 재면 되지만, 범용 모델은 알려진 작업의 성능뿐 아니라 모델이 수행할 수 있는 새로운 작업을 발견하는 일까지 평가의 몫이 됐다 — 때로는 사람의 능력을 넘어서는 작업까지도.

이런 어려움에도 평가에 대한 투자는 여전히 모델링·학습·오케스트레이션 개발에 못 미친다. 인기 있는 AI 저장소 상위 1,000개를 분석하면 평가 관련 저장소는 다른 분야보다 뚜렷하게 적고, 그 결과 많은 팀이 즐겨 쓰는 프롬프트 몇 개로 결과를 "대략 확인"하는 즉흥적 방식에 머문다. 벤치마크 자체도 빠르게 낡는다 — 2018년 GLUE는 1년 만에 최고 점수에 도달해 2019년 SuperGLUE로 대체됐고, NaturalInstructions(2021)는 Super-NaturalInstructions(2022)로, 초기 파운데이션 모델이 널리 쓰던 MMLU(2020)도 MMLU-Pro(2024)로 대부분 대체됐다. 모델이 벤치마크에서 만점에 가까워지면 그 벤치마크는 더 이상 변별력이 없기 때문이다. 이런 어려움을 인정하는 것이 체계적인 평가로 가는 첫걸음이다.

2. 엔트로피와 교차 엔트로피

많은 파운데이션 모델은 여전히 언어 모델을 핵심 구성 요소로 쓰고 있어서, 언어 모델의 성능이 좋을수록 애플리케이션 전체 성능도 좋아지는 경향이 있다(강한 상관관계이지 완전한 설명은 아니다). 그래서 언어 모델링 지표를 이해하면 애플리케이션에 어떤 모델이 맞는지 판단하는 데 도움이 된다. 자기회귀 언어 모델은 대부분 교차 엔트로피나 그와 밀접한 퍼플렉시티를 최소화하도록 학습된다. 이 두 지표에 문자당 비트(BPC)·바이트당 비트(BPB)까지 더한 네 가지는 서로 밀접히 연결돼 있어, 하나만 알면 나머지 셋을 계산할 수 있다.

엔트로피는 토큰 하나가 평균적으로 담고 있는 정보량을 잰다. 정사각형 안의 위치를 설명하는 언어를 예로 들어 보자. 토큰이 "위/아래" 두 개뿐인 언어는 1비트로 표현할 수 있어 엔트로피가 1이다. 토큰이 "왼쪽 위/오른쪽 위/왼쪽 아래/오른쪽 아래" 네 개인 언어는 더 구체적인 정보를 전달하지만 표현하려면 2비트가 필요해 엔트로피가 2다. 직관적으로 엔트로피는 "다음에 올 것을 예측하기 얼마나 어려운가"를 보여준다 — 토큰이 2개인 언어는 4개인 언어보다 다음 토큰을 맞히기 쉽다.

교차 엔트로피는 언어 모델이 데이터셋의 내용을 얼마나 예측하기 어려워하는지 보여준다. 학습 데이터의 실제 분포를 P, 모델이 학습한 분포를 Q라 하면, 학습 데이터의 엔트로피는 H(P)이고 P와 Q가 얼마나 다른지는 쿨백-라이블러(KL) 발산 D(P‖Q)로 잰다. 이때 모델의 교차 엔트로피는 다음처럼 두 항의 합으로 분해된다.

H(P, Q) = H(P) + D(P‖Q)

교차 엔트로피는 비대칭이다 — P에 대한 Q의 교차 엔트로피 H(P,Q)와 Q에 대한 P의 교차 엔트로피 H(Q,P)는 값이 다르다. 언어 모델은 이 교차 엔트로피를 최소화하도록 학습되며, 학습 데이터를 완벽하게 학습했다면 D(P‖Q)가 0에 가까워져 모델의 교차 엔트로피는 학습 데이터 자체의 엔트로피에 대한 근삿값이 된다.

문자당 비트(BPC)와 바이트당 비트(BPB)는 토큰화 방식이 다른 모델끼리도 비교할 수 있게 해 준다. 어떤 모델은 단어를, 어떤 모델은 문자를 토큰으로 쓰기 때문에 "토큰당 비트"로는 서로 비교할 수 없다. 예를 들어 토큰당 비트가 6이고 평균적으로 토큰 하나가 문자 2개로 이뤄져 있다면 BPC는 6/2=3이다. 다만 BPC는 ASCII(문자당 7비트)와 UTF-8(문자당 8~32비트)처럼 인코딩 방식이 다양해 표준화가 어렵다는 문제가 있어서, 원본 데이터의 1바이트를 표현하는 데 필요한 비트 수인 BPB를 더 표준적인 지표로 쓴다. BPC가 3이고 문자당 7비트(1바이트=8비트 기준)라면 BPB는 3 ÷ (7/8) ≈ 3.43이다. BPB가 3.43이라는 것은 원본 1바이트(8비트)를 3.43비트로 표현할 수 있다는 뜻으로, 이 언어 모델이 원본 텍스트를 원래 크기의 절반 이하로 압축할 수 있다는 의미다.

참고 — 클로드 섀넌은 1951년 논문 「Prediction and Entropy of Printed English」에서 문자 단위 엔트로피 개념을 대중화했다. 그가 쓴 표현을 옮기면, "엔트로피는 어떤 의미에서 그 언어의 텍스트에서 문자마다 평균적으로 얼마나 많은 정보가 생성되는지 측정하는 통계적 파라미터"다.

3. 퍼플렉시티 해석과 활용 사례

퍼플렉시티(PPL)는 엔트로피·교차 엔트로피의 지수함수다. 실제 분포 P를 가진 데이터셋의 퍼플렉시티는 PPL(P) = 2^H(P)이고, 이 데이터셋에서 모델(분포 Q)의 퍼플렉시티는 PPL(P,Q) = 2^H(P,Q)다. 밑이 2인 이유는 엔트로피·교차 엔트로피의 단위를 비트로 뒀기 때문이다. 텐서플로·파이토치 같은 프레임워크는 자연로그(nat)를 단위로 쓰는데, 이 경우 퍼플렉시티는 PPL(P,Q) = e^H(P,Q)가 된다. 앞서 본 4개 토큰짜리 위치 언어를 완벽하게 인코딩한 모델의 교차 엔트로피는 2비트이므로, 이 모델의 퍼플렉시티는 2² = 4다 — 다음 토큰을 고를 때 선택지가 4개 남아 있다는 뜻이다.

교차 엔트로피가 "예측하기 얼마나 어려운가"를 보여준다면, 퍼플렉시티는 "다음 토큰을 예측할 때 불확실성이 얼마나 큰가"를 더 직관적으로 보여준다. 값을 해석할 때 쓰는 세 가지 경험 규칙이 있다.

• 구조화된 데이터일수록 퍼플렉시티가 낮다. HTML처럼 <head> 다음에 </head>가 온다고 예측할 수 있는 구조화된 텍스트는 일상 텍스트보다 예측하기 쉽다.
• 어휘 크기가 클수록 퍼플렉시티가 높다. 선택할 수 있는 토큰이 많을수록 다음 토큰을 맞히기 어렵다 — 같은 모델이라도 아동용 도서보다 『전쟁과 평화』를 예측할 때 퍼플렉시티가 더 높고, 다음 단어보다 다음 문자를 예측할 때가 더 낮다.
• 컨텍스트 길이가 길수록 퍼플렉시티가 낮다. 참고할 수 있는 이전 토큰이 많을수록 불확실성이 줄어든다. 1951년 섀넌은 앞선 10개 이내 토큰만으로 교차 엔트로피를 계산했지만, 오늘날 모델은 수백에서 수만 개의 이전 토큰을 조건으로 퍼플렉시티를 계산한다.

! CAUTION — 퍼플렉시티는 SFT·RLHF 같은 사후 학습(2장 §3)을 거친 모델을 평가하는 데는 적절하지 않을 수 있다. 특정 작업을 더 잘 수행하도록 다듬을수록 다음 토큰 예측 능력은 오히려 떨어질 수 있어서, 언어 모델은 보통 사후 학습 후 퍼플렉시티가 높아진다("사후 학습이 엔트로피를 붕괴시킨다"고 말하는 사람도 있다). 양자화(수치 정밀도·메모리 사용량을 줄이는 기법, 7장 §메모리 병목 현상)도 예상치 못한 방식으로 퍼플렉시티를 바꿀 수 있다.

퍼플렉시티는 학습 시 성능 지표로 쓰이는 것 외에도 여러 용도가 있다. 원문의 표 3-1은 GPT-2의 모델 크기(117M~1,542M)가 커질수록 여러 데이터셋에서 일관되게 더 낮은(더 나은) 퍼플렉시티를 보인다는 것을 보여준다.

참고 — 표 손상 안내: 원문 표 3-1의 실제 수치는 PDF 추출 과정에서 행·열이 뒤섞여 신뢰할 수 없는 상태다. 이 표의 개별 숫자는 옮기지 않는다. 원문이 문장으로 명시한 결론만 전달한다 — "더 큰 GPT-2 모델들이 여러 데이터셋에서 일관되게 더 낮은 퍼플렉시티를 보인다."

퍼플렉시티의 다른 활용은 다음과 같다.

• 데이터 오염 탐지: 모델이 학습 중에 이미 본 텍스트에서는 퍼플렉시티가 가장 낮게 나온다. 특정 벤치마크 데이터에서 퍼플렉시티가 비정상적으로 낮다면, 그 벤치마크가 학습 데이터에 섞여 있었을 가능성이 높다는 뜻이고, 그러면 해당 벤치마크 점수를 신뢰하기 어렵다.
• 학습 데이터 중복 제거: 새 데이터의 퍼플렉시티가 충분히 높을 때만 학습 데이터셋에 추가하는 방식으로 활용한다.
• 비정상 텍스트 탐지: "우리 강아지는 여가 시간에 양자역학을 가르친다" 같은 기이한 문장이나 "집 고양이 가다 눈"처럼 의미 없는 텍스트는 예측하기 어려워 퍼플렉시티가 가장 높게 나타난다.

퍼플렉시티를 계산하려면 모델이 각 다음 토큰을 예측할 확률(로그 확률)을 알아야 하는데, 상용 모델 다수가 이 값을 공개하지 않는다는 점은 실무에서 부딪히는 현실적인 제약이다.

4. 기능적 정확성

기능적 정확성은 시스템이 의도한 기능을 실제로 수행하는지를 평가하는 방식이다. 모델에 웹사이트를 만들어 달라고 했을 때 생성된 웹사이트가 요구사항을 충족하는가, 레스토랑 예약을 부탁했을 때 실제로 성공하는가 — 이런 질문에 답하는 것이 기능적 정확성이며, 애플리케이션이 의도한 대로 동작하는지를 직접 재기 때문에 궁극적인 지표로 꼽힌다. 다만 측정을 자동화하기가 늘 쉬운 것은 아니다.

코드 생성은 자동화가 잘 되는 대표 사례다. 코딩에서 기능적 정확성은 흔히 실행 정확도를 의미한다 — 생성된 코드를 인터프리터에 넣어 유효한지 확인하고, 유효하다면 주어진 입력에 대해 올바른 결과를 내는지 확인한다. 코드는 보통 여러 시나리오에서 실행해 기대한 출력이 나오는지 확인하는 단위 테스트로 검증되며, 벤치마크 문제마다 여러 테스트 케이스가 함께 제공된다. HumanEval(OpenAI)의 실제 문제 하나를 보자. 아래 코드는 원문 추출 과정에서 등호(=)가 ==로 깨졌던 부분을 정정한 것이다.

from typing import List

def has_close_elements(numbers: List[float], threshold: float) -> bool:
    """주어진 수 목록에서 threshold보다 더 가까운 두 수가 있는지 확인한다.
    >>> has_close_elements([1.0, 2.0, 3.0], 0.5)
    False
    >>> has_close_elements([1.0, 2.8, 3.0, 4.0, 5.0, 2.0], 0.3)
    True
    """

# 테스트 케이스 — 각 assert 문이 하나의 테스트 케이스를 나타낸다
def check(candidate):
    assert candidate([1.0, 2.0, 3.9, 4.0, 5.0, 2.2], 0.3) == True
    assert candidate([1.0, 2.0, 3.9, 4.0, 5.0, 2.2], 0.05) == False
    assert candidate([1.0, 2.0, 5.9, 4.0, 5.0], 0.95) == True
    assert candidate([1.0, 2.0, 5.9, 4.0, 5.0], 0.8) == False
    assert candidate([1.0, 2.0, 3.0, 4.0, 5.0, 2.0], 0.1) == True
    assert candidate([1.1, 2.2, 3.1, 4.1, 5.1], 1.0) == True
    assert candidate([1.1, 2.2, 3.1, 4.1, 5.1], 0.5) == False

이 테스트가 왜 필요한지는 아래 대비로 바로 드러난다.

잘못된 예(엣지 케이스를 놓친 구현):

if numbers[i] - numbers[j] < threshold:   # 절댓값을 씌우지 않아, 음수 방향 차이를 걸러내지 못한다
    return True

올바른 예:

if abs(numbers[i] - numbers[j]) < threshold:
    return True

잘못된 구현은 numbers[i] < numbers[j]인 조합을 그냥 지나쳐 버려, 위 테스트 케이스 중 일부에서 실제로는 가까운 두 수가 있는데도 False를 반환한다 — 사람이 코드를 눈으로 보면 그럴듯해 보여도, 테스트 케이스를 실행해야 비로소 드러나는 오류다.

모델을 평가할 때는 문제마다 k개의 코드 샘플을 생성하고, 그중 하나라도 모든 테스트 케이스를 통과하면 그 문제를 해결한 것으로 본다. 이때 최종 점수인 pass@k는 전체 문제 중 해결한 문제의 비율이다. 예컨대 문제 10개 중 k=3일 때 5개를 풀었다면 pass@3 점수는 50%다. 샘플을 많이 생성할수록 그중 하나가 맞을 가능성이 높아지므로, pass@1 ≤ pass@3 ≤ pass@10 순으로 점수가 커지는 경향이 있다. HumanEval·구글의 MBPP(코드), 스파이더·BIRD-SQL·WikiSQL(텍스트-to-SQL) 같은 벤치마크가 모두 기능적 정확성을 지표로 쓴다.

기능적 정확성은 코드 생성에 국한되지 않는다. 테트리스를 플레이하는 봇은 획득 점수로, 에너지 소비를 최적화하는 작업은 절약한 에너지량으로 성능을 잴 수 있다 — 측정 가능한 목표가 있는 작업이라면 대체로 기능적 정확성으로 평가할 수 있다.

5. 참조 데이터 유사도 측정

기능적 정확성으로 잴 수 없는 작업이라면, AI의 출력을 참조 데이터(정답·표준 응답)와 비교하는 것이 일반적인 대안이다. 참조 데이터의 각 예시는 (입력, 참조 응답) 형태를 따르고, 하나의 입력에 여러 개의 참조 응답이 있을 수 있다. 참조가 필요한 지표는 참조 기반 지표, 필요 없는 지표는 참조 없는 지표라고 부른다. 참조 데이터는 사람이 만드는 것이 원칙이지만 비용·시간 문제로 최근에는 AI가 생성하고 사람이 검수하는 경우가 늘고 있다.

두 개방형 텍스트 사이의 유사도를 재는 방법은 크게 네 가지다 — ① 비교(평가자에게 같은지 판단하도록 요청), ② 정확한 일치, ③ 어휘적 유사도, ④ 의미적 유사도. 이 중 ①은 사람 평가자나 AI 평가자가 수행하는 방식이라 §7에서 다루고, 이 절에서는 수작업으로 설계된 지표인 ②~④를 살펴본다.

정확한 일치는 생성된 응답이 참조 응답 중 하나와 문자 그대로 같은지를 본다. "2+3은?"처럼 짧고 정확한 답을 기대하는 작업에 적합하지만, 두 가지 함정이 있다. 참조 답안이 포함되기만 하면 정답으로 인정하는 방식은 "안네 프랑크는 언제 태어났나요?"(정답 1929년)에 "1929년 9월 12일"이라고 답해도 정답으로 처리해 버릴 수 있고, 반대로 원문이 길고 복잡한 번역 문제("Comment ça va?" → "How are you?"/"How is everything?"/"How are you doing?")는 참조 목록에 없는 정답까지 나올 수 있어 정확한 일치가 거의 작동하지 않는다.

어휘적 유사도는 두 텍스트가 얼마나 겹치는지를 잰다. 가장 단순하게는 공통 토큰 수를 센다 — 참조 응답 "My cats scare the mice"에 대해 "My cats eat the mice"는 5단어 중 4단어가 겹쳐 80%, "Cats and mice fight all the time"은 5단어 중 3단어만 겹쳐 60%다. 편집 거리는 한 텍스트를 다른 텍스트로 바꾸는 데 필요한 삭제·삽입·대체 횟수를 세는 방식이고(예: 'bad'→'bard'는 1회 편집, 'bad'→'cash'는 3회 편집), n-gram 유사도는 개별 토큰이 아니라 연속된 토큰 시퀀스(1-gram·2-gram 등)의 겹침을 잰다. 이런 방식을 구현한 대표 지표가 BLEU·ROUGE·METEOR·TER·CIDEr이며, WMT·COCO Captions·GEMv2 같은 벤치마크가 사용한다.

어휘적 유사도의 약점은 두 가지다. 첫째, 참조 세트가 포괄적이지 않으면 좋은 응답도 낮은 점수를 받는다 — 어댑트의 멀티모달 모델 푸유가 정확한 이미지 캡션을 생성하고도 참조 캡션이 그 표현을 담고 있지 않아 낮은 점수를 받은 사례가 있다. 둘째, 참조 데이터 자체가 틀릴 수 있다 — WMT 2023 Metrics 공유 작업 주최 측은 자신들의 참조 번역에 오류가 많다는 것을 발견했고, 이는 참조 없는 평가 방식이 참조 기반 평가에 필적하는 성능을 내는 이유 중 하나로 꼽힌다. 또한 HumanEval에서는 잘못된 해답과 올바른 해답의 BLEU 점수가 비슷했다는 오픈AI의 관찰처럼, 어휘적 유사도 점수가 높다고 기능적 정확성까지 높은 것은 아니다.

의미적 유사도는 표현이 달라도 뜻이 같은지를 잰다. 'What's up?'과 'How are you?'는 어휘가 거의 겹치지 않지만 의미는 매우 비슷하고, 반대로 'Let's eat, grandma'와 'Let's eat grandma'는 겉보기 텍스트는 비슷해도 의미가 완전히 다르다. 이를 재려면 먼저 텍스트를 임베딩(§6)으로 바꾼 다음 코사인 유사도 같은 지표로 두 벡터의 유사도를 계산한다. BERTScore·MoverScore가 대표적인 의미적 텍스트 유사도 지표다. 참조 세트를 포괄적으로 만들 필요는 없지만, 신뢰성이 임베딩 알고리즘의 품질에 좌우되고 계산 비용도 상당하다는 단점이 있다.

! CAUTION — 의미적 유사도는 "정확한 평가" 범주로 분류했지만, 임베딩 알고리즘마다 서로 다른 임베딩을 만들어 내므로 주관적이라고 볼 여지도 있다. 다만 임베딩 두 개가 정해지면 그 사이의 유사도 점수 자체는 항상 정확하게(모호함 없이) 계산된다.

6. 임베딩 소개

컴퓨터는 숫자로 작동하므로, 모델은 입력을 먼저 처리 가능한 숫자 표현으로 바꿔야 한다. 임베딩은 원본 데이터의 의미를 담으려는 벡터 표현이다 — "the cat sits on a mat"이라는 문장이 [0.11, 0.02, 0.54] 같은 벡터로 표현되는 식이다. 실제 임베딩 벡터의 크기(원소 개수)는 보통 100~10,000 사이다. BERT·CLIP(대조적 언어-이미지 사전 학습)·Sentence Transformers 같은 오픈소스 모델이나, 오픈AI·코히어가 제공하는 API 형태의 비공개 모델로 임베딩을 만들 수 있다. 원문의 표 3-2를 정리하면 다음과 같다.

GPT·라마 등 대부분의 트랜스포머 기반 모델도 입력을 벡터로 바꾸는 임베딩 층을 내부에 포함하고 있어(2장 §2 모델링의 트랜스포머 아키텍처), 이런 모델의 중간 층에서 임베딩을 뽑아 쓸 수도 있지만 전용 임베딩 모델만큼 품질이 좋지 않을 수 있다.

임베딩 알고리즘의 목표는 원본 데이터의 본질을 담는 것이다. 이를 검증하는 큰 틀의 기준은 "더 비슷한 텍스트의 임베딩이 코사인 유사도 같은 지표로 쟀을 때 더 가까운가"다 — 'the cat sits on a mat'의 임베딩은 'AI research is super fun'보다 'the dog plays on the grass'에 더 가까워야 한다. 수학적으로, 생성된 응답의 임베딩을 A, 참조 응답의 임베딩을 B라 하면 코사인 유사도는 다음처럼 계산한다.

cosine_similarity(A, B) = (A·B) / (‖A‖ × ‖B‖)

여기서 A·B는 두 벡터의 내적, ‖A‖는 A의 유클리드 노름(각 원소를 제곱해 더한 뒤 제곱근을 취한 값)이다. 완전히 같은 두 임베딩의 유사도는 1, 완전히 반대되는 두 임베딩의 유사도는 -1이다. 임베딩 품질은 분류·주제 모델링·추천 시스템·RAG(6장 §검색 알고리즘) 같은 실제 작업에서의 유용성으로도 평가할 수 있으며, MTEB(Massive Text Embedding Benchmark)가 여러 작업에 걸쳐 임베딩 품질을 재는 대표 벤치마크다.

텍스트만이 아니라 모든 데이터 유형이 임베딩으로 표현될 수 있다. 전자상거래 기업은 제품 임베딩을, 핀터레스트는 이미지·그래프·쿼리·사용자 임베딩을 함께 활용한다. 최근 연구 흐름은 서로 다른 데이터 유형을 하나의 통합 임베딩 공간으로 매핑하는 멀티모달 임베딩이다. CLIP은 (이미지, 텍스트) 쌍으로 학습해 텍스트 인코더·이미지 인코더의 출력을 하나의 통합 공간에 투영하는 대표적인 초기 모델이고, ULIP은 텍스트·이미지·3D 포인트 클라우드를, ImageBind는 텍스트·이미지·오디오를 포함한 여섯 가지 데이터 유형을 하나의 임베딩 공간으로 묶는다. 통합 임베딩 공간에서는 낚시하는 남자의 이미지 임베딩이 '패션쇼'보다 '어부'라는 텍스트 임베딩에 더 가까워야 하며, 이런 성질 덕분에 텍스트로 이미지를 검색하는 것처럼 서로 다른 유형의 데이터를 넘나드는 검색이 가능해진다. 임베딩 개념은 6장의 벡터 검색과 8장 §데이터 큐레이션과 데이터 품질의 데이터 중복 제거를 포함해 이 책 전반의 근간이 된다.

7. AI 평가자

개방형 응답을 사람이 일일이 평가하기 어렵다 보니, 많은 팀이 AI로 AI를 평가하는 AI 평가자("LLM 평가자"·"AI 심판자")로 눈을 돌렸다. 아이디어 자체는 오래됐지만 실용적인 수준에 오른 것은 2020년 GPT-3 등장 이후다. 랭체인의 2023년 AI 현황 보고서에 따르면 그 플랫폼에서 이뤄진 평가의 58%가 이미 AI 평가자를 통했다.

쓰는 이유는 명확하다 — 사람 평가자보다 빠르고 쓰기 쉽고 비용도 저렴하며, 참조 데이터 없이도 작동해 실제 서비스 환경에서 바로 쓸 수 있다. 정확성·반복성·유해성·건전성·환각 등 어떤 기준이든 물어볼 수 있고, 근거까지 설명하게 할 수 있어 평가 결과를 검토하기에도 좋다. 연구에 따르면 특정 AI 평가자는 사람과 높은 상관관계를 보인다 — 정(Zheng) 등(2023)의 MT-Bench 실험에서 GPT-4와 사람의 일치도는 85%로, 사람들 간의 일치도(81%)보다도 높았고, AlpacaEval 연구진의 평가자는 사람이 매긴 LMSYS 챗봇 아레나 순위와 0.98의 거의 완벽한 상관관계를 보였다.

사용법은 프롬프트로 무엇을 시키느냐에 따라 셋으로 나뉜다. 다음은 각각을 보여주는 프롬프트 예시이며, 이미 책이 실제로 검증해 온 형태다.

상황 ① — 응답 하나의 품질을 독립적으로 평가:

다음 질의와 응답이 주어졌을 때, 질의에 대한 응답이 얼마나 좋은지 1부터 5까지의
점수로 평가하시오. 1은 매우 나쁨, 5는 매우 좋음을 의미한다.
질의: [질의]
응답: [응답]
점수:

상황 ② — 생성된 응답이 참조 응답과 같은지 판정:

다음 질의, 참조 응답, 생성된 응답이 주어졌을 때, 생성된 응답이 참조 응답과 같은지
평가하시오. True 또는 False를 출력하시오.
질의: [질의]
참조 응답: [참조 응답]
생성된 응답: [생성된 응답]

상황 ③ — 두 응답 중 더 나은 쪽 고르기(선호도 데이터 수집에 활용):

다음 질의와 두 응답이 주어졌을 때, 어느 응답이 더 나은지 A 또는 B로 출력하시오.
질의: [질의]
A: [첫 번째 응답]
B: [두 번째 응답]
더 나은 응답은:

평가자 프롬프트를 쓸 때는 ⓐ 모델이 할 작업, ⓑ 따라야 할 기준, ⓒ 점수 체계(분류·이산적 숫자·연속적 숫자) 세 가지를 명확히 밝혀야 한다. 지시가 구체적일수록, 점수별 예시가 포함될수록 성능이 좋아진다는 것이 실무에서 관찰된 규칙이다.

느슨한 프롬프트(무엇이 낮은 점수인지 기준이 없음):

이 응답이 질의에 잘 맞는지 1~5점으로 평가해줘.

구체적인 프롬프트(애저 AI 스튜디오의 관련성 기준 발췌 — 기준과 낮은 점수 예시까지 포함):

당신의 임무는 정답을 바탕으로 생성된 응답과 질의 사이의 관련성을
1부터 5까지 점수로 매기고, 이유도 제공하는 것입니다. 생성된 응답이
정답과 모순된다면 1~2점의 낮은 점수를 받습니다.
예: 질의 "하늘이 파란가요?" · 정답 "네, 하늘은 파랗습니다." ·
생성된 응답 "아니요, 하늘은 파랗지 않습니다." → 정답과 모순되므로 낮은 점수.

또한 언어 모델은 보통 숫자보다 텍스트를 더 잘 다뤄서, 연속 점수보다 분류나 좁은 범위의 이산 점수(보통 1~5)에서 더 잘 작동하는 것으로 보고된다.

한계는 크게 네 가지다.

• 비일관성: AI 평가자도 확률적이라 같은 입력에 같은 지시로 두 번 채점해도 다른 점수가 나올 수 있다. 정 등(2023)의 실험은 프롬프트에 채점 예시를 포함하면 GPT-4의 일관성이 65%에서 77.5%로 오른다는 것을 보였지만, 예시를 늘릴수록 프롬프트가 길어져 비용이 4배까지 늘었다 — 또한 일관성이 높아진다고 정확도까지 높아진다는 보장은 없다(같은 실수를 일관되게 반복할 수도 있다).
• 평가 기준의 모호성: 표준화되지 않아 오용하기 쉽다. MLflow·Ragas·LlamaIndex는 모두 "충실성"이라는 같은 이름의 기준을 두지만, MLflow는 1~5점, Ragas는 0/1, LlamaIndex는 YES/NO로 점수 체계가 전부 다르다. 같은 (컨텍스트, 응답)에 MLflow가 3점, Ragas가 1점, LlamaIndex가 NO를 낸다면 어느 쪽을 믿어야 할지 답이 없다. AI 평가자 자체도 시간이 지나며 업데이트되므로, 지난달 90%였던 점수가 이번 달 92%가 됐을 때 그것이 애플리케이션의 발전인지 평가자의 변화인지 구별하기 어렵다는 점도 같은 문제의 연장이다.
• 비용과 지연 시간 증가: 강력한 모델로 응답을 생성하고 그 응답을 다시 같은 모델로 평가하면 API 호출이 두 배가 되고, 기준을 여러 개(품질·사실 일관성·유해성 등) 두면 호출이 그만큼 더 늘어난다. 더 약한 모델을 평가자로 쓰거나 응답의 일부만 표본 검사하는 방식으로 비용을 낮출 수 있지만, 표본 검사는 일부 실패를 놓칠 위험이 있다. 평가를 응답 전송 전에 두면 위험은 줄지만 지연 시간이 늘어나는 트레이드오프도 함께 따라온다.
• 편향: 자기 편향(모델이 다른 모델보다 자기 응답을 후하게 평가 — 정 등의 실험에서 GPT-4는 자기 응답에 10%, 클로드-v1은 25% 더 높은 점수를 줬다), 첫 위치 편향(짝 비교에서 먼저 제시된 응답을 선호 — 사람의 최근성 편향과는 반대 방향), 장황성 편향(품질과 무관하게 더 긴 응답을 선호 — 우·아지(2023)는 GPT-4·클로드-1이 짧고 정확한 응답보다 길고 부정확한 응답을 선호한다는 것을 보였고, 사이토 등(2023)은 길이가 2배 이상 차이 나면 거의 항상 긴 쪽을 고른다는 것을 확인했다. 다만 두 연구 모두 더 강력한 모델일수록 이 편향이 줄어드는 경향도 함께 관찰했다). 그 밖에 상용 모델을 평가자로 쓸 때는 개인정보·지적 재산권 제약도 함께 고려해야 한다.

특화된 평가자 세 가지도 눈여겨볼 만하다. 보상 모델은 (프롬프트, 응답)을 받아 품질 점수를 내며, 구글의 캐피(Cappy, 2023)는 파라미터 3.6억 개짜리 경량 평가 모델로 RLHF에 꾸준히 쓰여 왔다. 참조 기반 평가자는 (후보 응답, 참조 응답) 또는 (프롬프트, 생성된 응답, 참조 응답, 채점 기준)을 받아 유사도·품질 점수를 낸다 — BLEURT·Prometheus가 대표적이다. 선호도 모델은 (프롬프트, 응답1, 응답2)를 받아 어느 쪽이 더 나은지 판단과 근거를 함께 낸다 — PandaLM·JudgeLM이 그 예다. 평가자가 평가받는 모델보다 강력해야 하는지에 대해서는 의견이 갈린다 — "노래가 좋은지 판단하는 것은 누구나 할 수 있지만 직접 만들 수 있는 사람은 많지 않다"는 관점에서는 더 약한 모델도 평가자로 충분할 수 있다고 본다. 기본적인 검증 수준에서는 모델이 스스로를 평가하는 자기 평가(자기 비평)도 유용하며, 응답을 스스로 고쳐 개선하도록 유도하는 데 쓰이기도 한다. 평가자를 프롬프트로 구성하는 세부 요령은 5장 §명확한 지시와 충분한 컨텍스트에서 더 다룬다.

8. 비교 평가를 통해 모델 순위 정하기

모델을 평가하는 이유는 점수 자체보다 "어떤 모델이 가장 적합한가"를 알고 싶어서인 경우가 많다. 순위를 매기는 방법은 두 갈래다. 개별 평가는 각 모델을 독립적으로 채점한 뒤 점수로 순위를 매긴다(댄서 한 명씩 채점해 최고점자를 뽑는 것과 같다). 비교 평가는 모델들을 서로 겨루게 해 비교 결과로 순위를 계산한다(같은 무대에서 겨루게 한 뒤 심사위원이 더 마음에 드는 쪽에 투표하는 것과 같다). 응답 품질이 주관적일 때는 대체로 구체적인 점수를 매기는 것보다 어느 쪽이 나은지 고르는 비교가 더 쉽다.

AI 분야에서 비교 평가는 2021년 앤트로픽이 모델 순위를 매기는 데 처음 사용했고, LMSYS의 챗봇 아레나가 이 방식을 대중화했다 — 커뮤니티가 진행한 일대일 비교를 점수화해 순위를 매긴다. 모델 간 비교를 경기라 부르며, 다음처럼 경기 기록이 쌓인다.

모델이 둘뿐이면 순위는 간단하다 — 승률이 더 높은 쪽이 위다. 하지만 모델 수가 늘면 순위 매기기가 훨씬 까다로워진다. 다섯 개 모델의 승률 예시를 보자(A>B는 A가 B보다 선호된다는 뜻).

이런 승률 표에서 순위를 계산하는 데는 Elo·Bradley-Terry·TrueSkill처럼 스포츠·비디오 게임에서 검증된 알고리즘을 가져다 쓴다. 챗봇 아레나도 처음엔 Elo를 썼지만, 평가자·프롬프트 순서에 민감하다는 것을 발견하고 Bradley-Terry로 바꿨다(다만 점수를 Elo 스케일처럼 보이도록 변환해 계속 "Elo 점수"라 불렀다). 순위가 정확하다는 것은 더 높은 순위의 모델이 더 낮은 모델과 겨뤄 이길 확률이 50%를 넘는다는 뜻이며, 결국 모델 순위 매기기는 과거 경기 결과로 미래 경기를 예측하는 문제나 다름없다.

비교 평가의 과제는 세 가지다.

• 확장성 병목: 비교할 모델 쌍의 수는 모델 수의 제곱에 비례해 늘어난다. 2024년 1월 LMSYS는 모델 57개를 244,000번 비교했지만, 이는 모델 쌍(1,596개)당 평균 153번에 불과해 다양한 작업을 고려하면 충분치 않다. 순위 알고리즘은 보통 전이성(A>B, B>C면 A>C)을 가정해 모든 쌍을 직접 비교하지 않아도 되도록 해 주지만, 사람의 선호도가 실제로 전이성을 갖는지는 불분명하고 서로 다른 모델 쌍이 서로 다른 평가자·프롬프트로 평가되면서 비전이성이 생길 수 있다는 지적이 여러 논문에서 나온다.
• 표준화·품질 관리의 부재: 커뮤니티 크라우드소싱(챗봇 아레나 방식)은 다양한 비교를 얻고 조작하기도 비교적 어렵다는 장점이 있지만, 평가 기준이 없어 사실 관계를 확인하지 않고 그럴듯한 오답을 선호할 위험, 사용자의 선호(예의 바른 응답 대 필터링되지 않은 응답)가 활용 사례마다 다를 수 있다는 문제, 실제 업무 환경을 반영하지 못하는 즉흥적 프롬프트 문제가 함께 따라온다 — 2023년 공개된 챗봇 아레나 프롬프트 33,000개 중 'hello'·'hi' 계열만 180개(0.55%)였고, 특정 수수께끼 하나가 44번 반복됐다. 공개 순위표는 사내 문서 검색으로 컨텍스트를 보강하는 RAG 같은 고급 기능도 지원하지 않아, 그 모델이 RAG 시스템에서 잘 동작할지는 별도로 확인해야 한다. 이를 완화하려면 미리 정한 프롬프트로 제한하거나(다양성을 잃는다), 신뢰할 수 있는 평가자만 쓰거나(비용이 커지고 비교 횟수가 준다), 실제 제품 사용 흐름에 비교를 통합하는(사용자가 전문가가 아니면 판단이 어렵다) 방법이 쓰인다.
• 비교 성능이 절대 성능을 보장하지 않음: 모델 B가 A보다 순위가 높다는 결과만으로는 "B는 좋고 A는 나쁘다"인지 "둘 다 나쁘다"인지 "둘 다 좋다"인지 알 수 없다. 승률이 51%인 모델이 실제 문제 해결 능력에서 얼마나 차이가 나는지도 활용 사례마다 다르며, 비용까지 고려하면 승률 차이만으로 교체 여부를 판단하기 어렵다.

이런 한계에도 비교 평가에는 분명한 강점이 있다. 모델이 사람의 성능을 뛰어넘게 되면 사람 평가자가 구체적인 점수를 매기기는 어려워도 두 응답 중 어느 쪽이 나은지는 여전히 구별할 수 있어(라마 2 논문의 관찰), 비교가 유일한 대안이 될 수 있다. 참조 데이터로 모델을 학습시키는 것 같은 편법을 쓰기 어려워 상대적으로 조작이 힘들고, 모델이 완벽한 점수에 도달하면 무용지물이 되는 고정 벤치마크와 달리 더 강력한 모델이 계속 나와도 포화되지 않는다. AI 모델이 강력해질수록 평가는 더 중요해지고, 정확한 평가(§4~§6)와 주관적 평가(§7~§8)를 함께 쓰는 체계적 접근이 다음 장(4장)에서 이어진다.

핵심 개념 정리

실무 체크리스트

• [ ] 이 작업에 정답이 하나뿐인지, 여러 개 있을 수 있는지 먼저 구분했는가?
• [ ] 코드·SQL처럼 실행해서 확인할 수 있는 작업인데도 굳이 어휘적 유사도로 채점하고 있지 않은가?
• [ ] 참조 응답 세트가 있는데, 그 세트가 "있을 수 있는 정답"을 얼마나 포괄하는지 확인했는가?
• [ ] AI 평가자를 쓸 때 작업·기준·점수 체계 세 가지를 프롬프트에 모두 명시했는가?
• [ ] 같은 평가를 두 번 돌려서 점수가 일관되게 나오는지 확인했는가?
• [ ] AI 평가자에 위치를 바꿔 같은 비교를 두 번 시켜, 첫 위치 편향이 있는지 확인했는가?
• [ ] 지난달과 이번 달 점수를 비교하기 전에, 평가자 모델·프롬프트가 그대로였는지 확인했는가?
• [ ] 비교 평가에서 나온 "B가 A보다 낫다"는 결과를, 실제로 B가 우리 서비스에 얼마나 좋은지와 혼동하고 있지 않은가?
• [ ] 퍼플렉시티로 모델을 비교할 때, 두 모델의 토큰화 방식이 같은지 확인했는가?

연습문제

1. (지표 선택) 챗봇이 사용자의 질문에 프랑스어 문장을 영어로 번역해 주는 기능을 평가하려 한다. 참조 번역 3개가 있다고 할 때, 정확한 일치·어휘적 유사도·의미적 유사도 중 어느 것을 우선 검토하겠는가? 각 방법의 한계를 근거로 설명하라.
2. (퍼플렉시티 해석) 같은 모델이 일상 대화 텍스트에서는 퍼플렉시티 40, 자사 API 문서(형식이 고정된 코드 예제 포함)에서는 퍼플렉시티 8을 보였다. 이 결과만으로 "모델이 API 문서를 더 잘 이해한다"고 결론 내릴 수 있는가? 이 장의 해석 규칙을 근거로 답하라.
3. (pass@k 함정) 코드 생성 모델의 pass@10 점수가 pass@1보다 훨씬 높게 나왔다는 보고를 받았다. 이것이 반드시 모델의 코드 품질이 좋다는 뜻인지, 아니면 다른 이유가 있을 수 있는지 설명하라.
4. (AI 평가자 설계) 사내 고객 상담 챗봇의 응답이 "친절한 어투를 유지하는가"를 AI 평가자로 자동 채점하려 한다. 이 장의 프롬프트 설계 요령(작업·기준·점수 체계)에 따라 프롬프트의 뼈대를 설계하고, 이 평가자에서 어떤 편향이 가장 먼저 걱정되는지 밝혀라.
5. (개별 평가 vs 비교 평가) 신규 모델 하나를 기존 서비스에 투입할지 결정해야 한다. 비교 대상 모델이 이미 3개 운영 중이라면 개별 평가와 비교 평가 중 어느 쪽을 우선 적용하겠는가? 모델 수가 30개로 늘어난다면 답이 달라지는가?

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-12) — 이 장이 설명하는 개념(엔트로피·퍼플렉시티·유사도 지표·AI 평가자의 원리)은 그대로 유효하다. 바뀐 것은 이 장이 예시로 든 조직의 이름과, 편향 완화 기법의 성숙도다.

• LMSYS 챗봇 아레나 → LMArena → Arena. 이 장 §8이 예시로 든 LMSYS 챗봇 아레나는 2025년 1월 "LMArena"로 개명하며 독립 회사가 됐고, 2026년 1월 28일 다시 "Arena"로 리브랜딩해 현재 arena.ai에서 운영된다. 같은 달 시리즈 A 투자(1억 5,000만 달러, 기업가치 약 17억 달러)를 유치했다. 순위 계산 원리(익명 쌍대 비교 → Bradley-Terry 점수화)는 이 장의 설명과 같다. Arena
• AI 평가자 편향 완화가 표준 관행으로 자리 잡았다. 이 장 §7이 설명한 자기 편향·첫 위치 편향·장황성 편향은 여전히 관찰되지만, 최근에는 같은 비교를 응답 순서를 바꿔 두 번 채점해 판정이 갈리면 동점으로 처리하는 위치-일관성 검사, 채점 모델을 생성 모델과 다른 계열로 두는 방법이 널리 쓰이는 완화책으로 자리 잡았다. A Survey on LLM-as-a-Judge (Gu et al.)
• 다만 "심사위원을 여러 개 모으면 더 믿을 만하다"는 가정에는 한계가 확인됐다. 같은 모델 계열의 심사위원 여러 개를 모아도 오차가 서로 상관돼 있어, 패널의 실질적인 정보량이 심사위원 수보다 훨씬 적다는 조사 결과가 나왔다 — 이 장 §7의 "AI 평가자 팀 간 판정 차이" 논의를 뒷받침하는 최근 근거다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식·원논문, 생존 확인 2026-09-12)

• MT-Bench·Chatbot Arena 원논문 — §7의 GPT-4·사람 일치도 85% 실험, §8의 Elo 순위 계산 배경의 출처. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023)
• HumanEval(Codex) 원논문 — §4의 has_close_elements 문제·pass@k 지표의 출처. Evaluating Large Language Models Trained on Code (Chen et al., 2021)
• BLEURT 원논문 — §7의 참조 기반 평가자 예시(BLEURT 점수 -2.5~1.0)의 출처. BLEURT: Learning Robust Metrics for Text Generation (Sellam et al., 2020)
• MTEB 원논문 — §6의 임베딩 벤치마크 출처. MTEB: Massive Text Embedding Benchmark (Muennighoff et al., 2023)
• LLM-as-a-Judge 서베이 — §7 편향·한계 논의의 최신 동향 확인용. A Survey on LLM-as-a-Judge (Gu et al.)

더 해보기 — 읽고 끝내지 않으려면

• HumanEval의 has_close_elements 문제를 실제로 실행해, 이 절의 "잘못된 예"(절댓값 누락)가 어떤 테스트 케이스에서 실패하는지 직접 확인해 본다.
• 같은 질의·응답 쌍을 §7의 상황① 프롬프트로 두 번 채점해, 점수가 완전히 같게 나오는지 비교해 본다(비일관성 체감).

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (지표 선택) 번역처럼 하나의 입력에 여러 정답이 있는 개방형 작업에서는 정확한 일치가 거의 작동하지 않는다 — 참조 목록에 없는 표현("How is it going?")까지 정답일 수 있기 때문이다. 어휘적 유사도(BLEU 등)는 계산이 빠르지만 표현만 다른 정답을 낮게 채점할 위험이 있으므로, 참조 3개로는 다양한 표현을 포괄하기 어렵다는 점을 감안해 의미적 유사도(임베딩 기반)를 우선 검토하고, 예산이 허락하면 사람 또는 AI 평가자의 비교 평가로 보완하는 것이 이 장의 논리에 맞는다.
2. (퍼플렉시티 해석) 아니다. 이 장의 해석 규칙에 따르면 구조화된 데이터(API 문서·코드 예제)는 그 자체로 예측하기 쉬워 퍼플렉시티가 낮게 나오는 경향이 있다 — HTML 태그가 서로를 예측 가능하게 만드는 것과 같은 이유다. 두 텍스트의 어휘 크기·구조화 정도가 다르므로, 퍼플렉시티 차이만으로 "이해도"를 비교하는 것은 이 장이 경고한 함정에 해당한다.
3. (pass@k 함정) 반드시 그런 것은 아니다. pass@k는 k개의 샘플 중 하나라도 통과하면 해결로 치므로, 샘플을 더 많이 생성할수록(k가 클수록) 우연히 통과하는 샘플이 나올 확률 자체가 높아진다. 따라서 pass@10이 pass@1보다 높은 것은 어느 정도 예상된 현상이며, 코드 품질이 좋아졌다고 단정하려면 같은 k에서의 점수 변화나 실제 배포 시나리오(k=1에 가까운 상황)에서의 성능을 함께 봐야 한다.
4. (AI 평가자 설계) 작업은 "상담 응답이 친절한 어투를 유지하는지 판정", 기준은 "존중하는 표현·과도한 격식/무례함 여부를 구체적 예시와 함께 판단", 점수 체계는 좁은 이산 척도(예: 1~5, 각 점수의 응답 예시 포함)로 설계한다. 이 평가자에서는 응답이 길고 격식을 갖춘 문장일수록 "친절하다"고 오판할 수 있는 장황성 편향이 가장 먼저 걱정되는 지점이다 — 어투 판정과 분량이 실제로는 무관해야 하기 때문이다.
5. (개별 평가 vs 비교 평가) 비교 대상이 3개뿐이라면 모델 쌍이 최대 6개(4개 모델 기준)에 불과해 비교 평가로 직접 승률을 재는 것이 충분히 실용적이다. 모델 수가 30개로 늘면 모델 쌍이 수백 개로 급증해(확장성 병목) 모든 쌍을 다 겨루게 하기 어려워지므로, 개별 벤치마크 점수로 먼저 후보를 추리고 상위 후보끼리만 비교 평가를 적용하는 이단계 접근이 더 현실적이다.